[ResponseOps][Alerting v2] Move episodes time filter inside query, include previous actions - #290452

⚙️ Environment Setup

Add the following flag to your kibana.dev.yml:

xpack.alerting_v2.enabled: true

Then navigate to Stack Management > Advanced settings > Global, and enable Alerting v2

You need an episode that has been active for a while (i.e. more than an hour), with a tag and an ack added shortly after it started.

✅ Happy Path

1. Open the episodes list with Last 15 minutes selected
2. The episode row shows its tags and the ack indicator
3. The duration cell shows ≥ followed by the duration seen inside the range, and hovering it explains why
4. Widen the range to include the episode start: the ≥ goes away and the duration becomes the full one

⚡️ Edge Cases

1. Open the flyout of a ≥ row: it shows the full duration and the same tags and ack
2. The acknowledged and snoozed KPIs count the episode on the short range too
3. Filtering by one of its tags still returns the episode on the short range

• The duration is still clamped to the range, but at least it's flagged with a symbol and explanation in the cell. To make it exact at the same cost some work on the data itself is necessary. I.E. have the director write the episode start on each event.
• Rules with pending_count: 0 skip the pending state, so when no earlier episode of the same series is in range we can't tell whether we saw the start, and the row shows ≥ even when the duration is exact.
• The $.alert-episodes view has the same aggregation shape and Discover pushes its own range down, so the profile is not covered by this change.

The range is sent as a request filter (bool.should: [type == "alert" AND range, exists(action_type)]) through input.filters instead of the esql function's timeField, so ES still bounds the .rule-events scan at the Lucene level and every .alert-actions doc passes. Measured on 2M events at 12h: 0.18s vs 0.11s before.

I first tried selecting the episodes in range with an IN (subquery) and aggregating their full history (@adcoelho's suggestion), to fix the duration too. ES does not push the subquery down: 28s on the same data. A literal id list is pushed down (0.3s), but that means two requests.